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a parsing algorithm us€Wj)y said module to pattern- recognize said text- 
based telephone number cont^ined'^in said text-based information other than 
said previously iconified informatiop of said Web page. 



5 REMARKS 

3-4. 35 U.S.C. § 103. The Examiner has rejected Claims 1-22 under 35 
U.S.C. §1 03(a) as being unpatentable over Shachar (U.S. Patent No. 
5,923.736)(Shachar '592) in view of Shachar et al. (U.S. Patent No. 
10 5,764,736)(Shachar '576). 

4a. The Examiner stated that, as per claims 1, 8-12 and 14-22, "Shachar '592 
teaches a method of performing on an electronic document containing text 
information during communication which comprises the steps of: 

15 

parsing (Fig. 7-8, Hypertext Parser, Parse HTML data, a web browser 
includes a parsing module for parsing the text information for identifying 
telephone number as <1 -800-1 23-4567>, automatically dial the number 
without the user to enter phone number); and 

20 

adding code to form a telephone icon such (as a) screen label, a graphic 
button (adding code to create a hot link such as a graphic button, 
hyperlink, col. 1 1, lines 23-35, creating a graphic image with a telephone 
number)." 

25 

Furthermore, the Examiner noted that "the parser module is well known in the 
art to interpret the text information and generates HTML code to display to the 
viewer at the server or user terminal wherein Web Browser parses code (col. 3, 
lines 5-37), parsing the text information and creating graphic image with retrieve 
30 data and display it on a screen, col. 16, lines 1-7, "Parsing Module is inhereritly 
matching the telephone number with a creating graphic image". Col. 16, lines 
65, address book)." 

The Examiner conceded that Shachar '592 fails to disclose fully a step of 
35 recognizing a telephone number. However, the Examiner stated that "in the 
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same field of endeavor, Shachar ('576) discloses a method of recognizing a 
telephone number (See Fig. 4a, Ref 410)." 

Applicant disagrees that Shachar '576 discloses a method of recognizing a 
5 telephone number, and submits that, even in combination, Shachar '592 and 
Shachar '576 fail to meet the claimed invention. 

Analysis of Shachar *592. Shachar discloses a HyperText Markup 
Language (HTML) based telephone apparatus, as summarized in the Abstract, 
10 wherein: 

"the telephone/terminal device includes a display screen, input device, 
telephone interface, data communications interface (e.g., modem), a 
processor and memory. A hypertext markup language interpreter 

15 resident within the telephone/terminal device provides the basis of a 

hypertext based GUI. Resident hypertext documents stored within the 
memory of the device control user interface to essential functions such as 
setup and configuration, dialing, data access, etc. One aspect of the 
invention is directed to using HTML and TCP/IP (Internet "World Wide 

20 Web" compatible interpreter and protocols) to provide seamless access 

to Internet-hosted hypertext documents in a device which requires no 
computer training or expertise of the user thereof," 

The Examiner noted that "the parser module is well known in the art to interpret 
25 the text information and generates HTML code to display to the viewer at the 
server or user terminal wherein Web Browser parses code." Applicant 
disagrees. While the parser module processes basic {i.e. untagged or un- 
iconified) text information to display the text within an HTML document, the 
parser module does not add HTML code beyond that which is previously 
30 defined for the HTML document. 

The introduction of hypertext information is seen in col. 3, lines 5-37 of Shachar 
'592, wherein: 

35 "A hypertext document can be made up of data related to text, linked 

markup elements and anchors. The data stored in a hypertext document 
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file is processed by a hypertext markup language interpreter, such as a 
"browser" program. When the browser processes the text data, that data 
will be used to format and display the text on a screen. A linked markup 
element provides the browser with an address of another stored file and 
an action to be taken with the data at that address. For example, a linked 
markup element can point to a graphical company logo. While scanning 
the entire document, the browser will reach the marking element, 
proceed to the specified address of the data associated with the logo, 
retrieve the data, create the graphical image and display it on the screen, 
all in accordance with the linked markup element . An anchor is the 
address of another hypertext document in the interconnected hypertext 
web, and a representation of that document. For example, the 
representation might be "on-line documents". When the browser reaches 
this anchor, it will display the representation on the screen as, for 
example, the text "on-line documents" appearing in a highlighted 
manner. This displayed image of the highlighted text is known as a 
hyperlink. Thus, a hyperlink can be considered as being the visible 
depiction of an anchor. The user has the option, at any time, of selecting 
any of the hyperlinks displayed on the screen with a suitable input 
device, e.g. a keyboard or mouse. When a hyperlink is selected, the 
browser accesses the address stored in the anchor represented by the 
hyperlink, retrieves the hypertext document stored at that address, and 
displays it on the screen. Thus, in our example, a list of documents 
available on line, perhaps with its own hyperlinks, will be displayed. It 
should be noted that the terms "hyperlinked" and "hypertext-based" are 
used synonymously herein." 

While the browser processes the text data, the data is used to format and 
display the text on a screen. The browser/parser interprets this data, which 
30 already includes previously defined "hyperlinks" (/.a previouslv defined linked 
markup elements), and uses the data, to format and display the text on a screen, 
to include the previously defined "hyperlinks". 

Transfer between Hypertext documents is disclosed in Shachar '592, on col. 16, 
35 lines 1-7, wherein: 
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"FIG. 8 shows how a corresponding sequence of events is carried out 
when the invention is employed. Once the user is ready to select a 
hyperlink , the relevant driver corresponding to the user's input device 
(normally a touch screen) is invoked (event 1). It passes the data directiv 
5 to the Hypertext Presentation Services module (event 2). This module 

provides the required visual feedback to the user on the display, and 
prepares the required HTTP request (event 3) which it sends through the 
modem driver (event 4) to the remote Internet server. When the response 
is received , the modem driver (event 4) transfers the data , which is a 
10 hypertext document, to the Hypertext Parsing Services module (event 5), 

which translates the data into an intermediate form accessible to the 
Hypertext Presentation Services module (event 6) which displays the 
new document to the user. When done, the system awaits the next user 
input, in response to which this process is restarted." 

Shachar '592 clearly discloses a basic transfer between hypertext documents, 
upon the selection of previously defined hyperlinks. For example. At event 5 in 
FIG. 8, the modem driver transfers the data, which is already a hypertext 
document, to the Hypertext Parsing Services module. At event 6, the Hypertext 
Parsing Services module translates the data into an intermediate form 
accessible to the Hypertext Presentation Services module. 



15 



20 



The Hypertext Parsing Services module simply acts upon the "hypertext 
document data" (which may include text), and translates the "hypertext 

25 document data" into an "intermediate form", which is accessible to the Hypertext 
Presentation Services module. The Hypertext Parsing Services module of 
Shachar '592 does not inherently create graphic images, or icons, to be 
associated with text that is not previously defined as a hyperlink, as the 
Examiner suggests. The browser/parser does not interpret text information and 

30 generate HTML code which "adds" a hypertink to text information which does 
not already have an associated hyperlink. 

The Examiner stated that the step of adding code (to create a hot link such as a 
graphic button, hyperlink), is disclosed on col. 11, lines 23-35, wherein: 

35 
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" Hypertext documents can contain markup elements which request a 
variety of different actions. For example, a hypertext document might 
contain a screen label describing where to call to talk to someone about 
a particular product or topic, e.g., "For further information call 1-800-123- 
5 4567 ", and would provide a graphical "button" hyperlink on the screen to 

automatically initiate the call by invoking a dialing procedure . Further, via 
a parallel data session and/or electronic mail, a service provider 
contacted in this manner can leave further information (e.g., additional 
hypertext document locations, specific messages, etc.). This permits 
10 direct interaction with a service provider via the telephone/terminal 

device 100." 

Applicant submits that the system of Shachar '592 clearly already includes a 
"graphical button hyperlink" with the associated phone number. There is no 
1 5 teaching of "adding code" to "create" a hot link, as the Examiner suggests. The 
browser simply processes the hypertext data, which may include previously 
defined hyperlinks. 

As well, the Examiner suggested that Shachar '576 discloses a method of 
20 recognizing a telephone number (See Fig. 4a, Ref 410). Applicant disagrees. 

Analysis of Shachar '576- As seen in the Abstract of Shachar '576, 
techniques are disclosed "for switching from a data session to a voice session, 
and then back to the data session" wherein a primary "data connection is 
25 established between a user's terminal and a communications network, which 
provides the user terminal with a tag identifying a voice network address ... to 
which a voice connection can be established. The user initiates a voice 
connection (session) with the service provider by selecting a displayed service 
object associated with the service tag". 

30 

The data session in Shachar '576 is therefore initially provided with a 
selectable "tag" which identifies a voice network address, to which a voice 
connection can be established. 

35 However, Shachar does '576 not teach the identification of telephone 
numbers within the text-based information of an electronic document. Each of 
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the telephone numbers in Shachar '576 already include a "service tag", which 
are then selectable by a user. 

Parsing of an Electronic Document. Shachar '576 generally refers to a 
5 standard browser program, which produces a HTML display at a user terminal, 
in response to the embedded information {e.g. such as existing text objects, 
graphic objects, and hyperlinks). As stated in Shachar '576, on col. 9, lines 4- 
16: 



10 "It is assumed, for purposes of this description, that the terminal 100 has 

a browser" program associated with it. "Browser" programs are the 
instrumentality by which a user "navigates" information stored on a data 
communication network such as Internet. These browser programs 
recognize the formatting and link information stored with 

15 hyper-linked hypertext documents (described hereinabove) and 

generate appropriately formatted displays from data and formatting 
information contained in the document. Further, browser programs are 
capable of retrieving and storing/displaying hyper-linked documents 
when a hyper-link is activated by a user (usually by selecting a hyper-link 

20 object on a display screen". 



Therefore, as Shachar '576 clearly states, it is the "browser program" which 
"recognizes" the "formatting and link information stored with hyper-linked 
hypertext documents". The browser program simply recognizes previously 
25 defined {i.e. "stored") formatting and link information, and uses this previously 
defined link information to "generate appropriately formatted displays from data 
and formatting information contained in the document". 

Such standard browser program functions, as described by Shachar '576, are 
30 also disclosed in the Application as filed, on page 2, lines 1-10, wherein: 

"A Web page is encoded in Hypertext Markup Language (HTML). An 
HTML document is a plain-text (ASCII) file that uses tags to denote the 
various elements in the document. An element may include an attribute, 
35 which is additional information that is included between tags. 
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HTML can be used to link text and/or images, such as icons, to another 
document or section of a document. The user activates a link by clicking 
on it, and the linked database is directly accessed. Links are used to 
access related information, or to contact a person or entity. However. 
5 information on a Web page must have the requisite HTML tags to be an 

active link. " 

However, not all information contained within a web page includes a previously 
defined HTML tag. As disclosed in Shachar '576, on col. 9, lines 19-33, and as 
10 seen in Fig. 2, a disclosed electronic business card (200) typically contains 
several types of information, including textual information (210), graphical 
information (220), tags (230), controls (240) having hyper-link connections 
(242), and "contact" information (250) having defined action links (252). 

15 However, information which does not include an HTML tag is not readily usable 
to automatically perform HTML functions, as disclosed in the Application as 
filed, on page 2, lines 12-24, wherein: 

"Web pages often contain additional information such as telephone 
20 numbers. These phone numbers appear as informational numbers, for 

example, for customer service, marketing materials, further information, 
or for advertising...." 

"However, these phone numbers are provided on the Web as 
25 text. HTML cannot be used to dial a telephone number over the Internet. 

Rather, the user must first search the text to locate a phone number. This 
search may be by visual inspection or by using a search engine to find a 
particular reference and its associated phone number. To access a 
number, the user must manually dial the number, or manually input the 
30 number into an automatic dialing program." 

As seen above, Shachar '576 discloses contact information (250) {i.e. 
telephone numbers) which already includes action links (252), by which 
actions may automatically be taken. Shachar fails to disclose the parsing of 
35 non-tagged information, such as textual information (210), to recognize phone 
numbers contained therein. 
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Neither the browser program, nor any other process disclosed by Shachar '576, 
parses text-based information other than previously iconified information within 
an electronic document. As well, there is no need to parse (/.e. analyze) the text- 
5 based information in Shachar '576, since the contact telephone numbers 
contained therein already contain selectable tags (See FIG. 2). While Shachar 
'576 is silent in regard to the handling of non-linked textual matter within the 
electronic business card, it is apparent that the standard browser program 
simply includes the stored non-linked textual matter during the generation of 
10 "appropriately formatted displays from data and formatting information 
contained in the document" (col. 9, lines 10-12). 

Recognition of Text-Based Telephone Numbers. As discussed above, 
the telephone numbers disclosed in Shachar '576 are already associated with 
15 selectable "tags" or "hyper-links". As Shachar '576 discloses, in col. 9, lines 23- 
33: 

"The electronic business card includes textual information 210, (e.g., a 
company name, an address, a contact person's name, a brief description 

20 of goods and services provided by a vendor, etc.), graphical information 

220 such as a logo or animated sequence, a set of "tags" 230, such as 
"buttons" on the screen, which enable use of the electronic business card 
to actuate certain actions..., a set of hyper-linked controls 240 for which 
the hyper-link connections 242 are defined, and "contact" information 

25 250 for which a set of action links 252 are defined". 

The phone tags, therefore, are previously defined "links", which are related to 
either a "communication network address" or to a "conventional phone number". 
The "textual information (210)" clearly does not include text-based telephone 
30 numbers, while the "contact information (250)" already includes the "action links 
(252)". 

There is no recognition of text-based telephone numbers by the system 
disclosed by Shachar '576. Selectable tags, which are already associated with 
35 a telephone number, are selectable by a user. The disclosed "recognition" 
within Shachar '576 is limited to the generation of a browser display, as 
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discussed above, based upon previously defined formatting and link 
information. 

Again, as seen in Shachar '576, in col. 9, lines 4-16: 

5 

These browser programs recognize the formatting and link 
information stored with hyper-linked hypertext documents 
(described hereinabove) and generate appropriately formatted 
displays from data and formatting information contained in the 
10 document." 

Applicant therefore submits that the "browser program" simply "recognizes" 
previously defined "formatting and link information" that is "stored" with a 
"hyperlinked hypertext document", and then generates a "formatted display", 
15 based upon the previously defined "formatting and link information". 

There is clearly no "recognition" of a text-based (/.e. previously untagged) 
telephone number in Shachar '576, which contains numbers and text symbols. 
The browser program simply generates a display screen, based upon the 
20 supplied information and pre-defined hyperlinks. 

Further support is seen in Shachar '576, in col. 9, lines 47-52: 

"Phone Tag(s): one or more phone numbers for voice communication 
with the vendor and/or contact person. Depending on the nature of the 
communication network, a phone tag may identify a 
communication network address to which voice 
communication may be established, or a conventional 
telephone number." 

Therefore, it is clear that the phone numbers in Shachar '576 are already 
associated with a selectable phone tag, which is included within a "navigable 
screen", whereby the phone tag may then be "selected" by a user. 



25 



30 
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Neither the browser application, nor any part of the system disclosed by 
Shachar '576, interprets non-hyperlink information {e.g. such as text-based 
information) to recognize telephone numbers contained therein. 

As well, the recognition of a text-based telephone number would be not 
obvious, based upon the teachings of Shachar '576. As disclosed in the 
Application as filed, on page 3, lines 20-23, and in page 6, lines 1-4: 

"A parsing algorithm applied to the text in the HTML document pattern- 
recognizes telephone numbers having a standard format, such as United 
States numbers or international phone numbers." 

Further support is seen in the Application, as filed, page 7, line 19 to page 8, 
line 15, wherein: 

Telephone numbers can include text, such as hyphens or parentheses, 
or spaces interspersed with numbers. The patterns in the Picture 
Formats are therefore defined by those text characters that can be before 
and in between numbers. Because some text characters void the 
pattern, the algorithm should take this into account (230). Thus, the 
algorithm can distinguish, for example, among parentheses surrounding 
an area code, parentheses surrounding a sentence, and a serial number 
containing both numbers and text characters. 

The patterns in the Picture Formats are also defined by the length of the 
number string. For example, U.S. area codes are usually three digits, 
and prefixes are usually three digits, followed by four final digits. 

The following is an example of an algorithm that supports U.S. phone 
numbers. The algorithm looks for the following patterns: 

'xxx*xxxx'; 

'x*xxx*xxxx'; 

'xxx**xxx*xxxx'; and 
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'x**xxx**xxx*xxxx'; 

where x represents a numeric digit, * represents one character, and ** 
5 represents either one or two characters, all of which can only be equal to 

") ", or " ", There is a first character case that is omitted which is a 
"+" or a "(" . 

Shachar '576 fails to recognize the problem of recognizing a text-based 
10 telephone number within previously uniconified information, which, as 
disclosed by the Applicant, may include text, such as hyphens or parentheses, 
or spaces interspersed with numbers, may include one of many formats, such 
as area codes, domestic or international formats. Furthermore, Shachar '576 
lacks any suggestion that the invention be modified to recognize a text-based 
15 telephone number from within previously uniconified text information. 

In response to the Examiner's rejections, and to further clarify the claimed 
invention, Applicant has amended independent Claims 1, 15 and 21, to more 
particularly point out and distinctly claim that the "text-based information other 

20 than previously iconified information" within the electronic document is parsed, 
to recognize a text-based telephone number. Support is seen in the 
Application, as filed, in Figure 1 and Figure 2; on Page 3, lines 12-23; on Page 
5, line 25 to page 6, line 4; and on page 7, lines 7-17. Applicant has also 
amended Claim 13 and Claim 16, to provide proper antecedent basis for the 

25 claims. Applicant submits there is no new matter. 

Conversion of a Text-Based Telephone Number to an Iconic 
Representation. The Examiner previously conceded that "Shachar '576 
does not explicitly teach converting a telephone number to an iconic 
30 representation". Applicant submits that it would not have been obvious to 
convert a text-based telephone number to an iconic representation. As 
discussed above, Shachar '576 discloses, in col. 5, line 43-52: 

"Tags defined within the electronic business card structure define 
35 phone numbers, fax numbers. E-mail network addresses, etc., by 

which a vendor can be contacted. The electronic business card can be 
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displayed on a display screen of the communication terminal device. 
Each tag is associated with a display "object" on the display 
screen, e.g. a "button" or a highlighted text or graphical object. When 
the object is selected by a user using an input device of the 
5 communication terminal device, the action defined by the tag 

associated with the selected object is perfornned". 

Therefore, in Shachar '576, telephone numbers are already associated with 
selectable tags, which are associated with a display "object" on the display 
10 screen, which are then "selected by a user". There is absolutely no reason in 
Shachar '576 to "convert a text-based telephone number to an iconic 
representation", since telephone numbers within the "electronic business card 
structure" are already associated with a selectable tag. 

15 While the Examiner previously stated that "a HTML program could be designed 
to establish a link between a service object with a data provided", Applicant 
submits that, while links may be established within an HTML program, there is 
no suggestion, express or implied, that the HTML program described by either 
Shachar '592 or Shachar '576 be modified to establish a link to text-based 

20 information other than previously iconified information. 

As disclosed by Shachar '576, in Col. 12, lines 61-65, and illustrated in Fig. 4a: 

"These flow charts (Figs. 4a, 4b, 4c) assume the use of a GUI guided by a 
25 hypertext markup language whereby a series of markup elements 

describe actions to be taken (including communications sessions 
addresses, etc.) upon selection of displayed screen objects". 

Further, as disclosed by Shachar, in Col. 13, lines 4-41: 

30 - 

"Fig. 4a is a flowchart showing actions to be taken by a data 
communications terminal ... in preparation for suspension of s first 
communications session in preference of a second communications 
session" ... "The markup element indicates a graphic element to be 

35 displayed and/or actions to be taken upon a user selection" ... "In a next 

step 406, it is determined whether the markup element identified in the 
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previous step 404 includes an alternative network address (/.e. whether it 
is necessary to establish a second communications session with a 
different destination ... if an alternative network address is not indicated, 
then a next step 408 simply displays any graphical object(s) associated 
with the markup element, and returns to the first step" ... "A next step 412 
retrieves and stores information related to the cost of communications 
with the alternative network address" ... "A next step 416 retrieves display 
information associated with the alternative network address indicated by 
the markup element, such as image, text, video and/or audio" 

Therefore, for information (e.g. text-based information) which does not already 
have an associated tag linked to an "alternative network address", the method 
"simply displays" the graphical object. Shachar '576 clearly teaches away from 
the analysis, recognition and iconification of information which is not previously 
defined to include a selectable tag to initiate a alternative communication 
session. 

Shachar '576 doesn't create icons, but merely provides navigation between 
communication sessions based upon previously defined "selectable" objects. 
20 As clearly disclosed in the present invention. Applicant provides selectability 
from objects (/.e. recognized text-based phone numbers) which are not 
previously defined as being selectable objects (e.g. by recognizing text-based 
phone numbers within text-based information other than previously iconified 
information, and making the recognized text-based phone numbers selectable 
25 {e.g. iconizing), none of which is taught by either Shachar '576 or Shachar '592. 

While Shachar '576 discloses basic transfer between a "data communication 
session" and a "voice communication session", both Shachar '592 and Shachar 
'576 are silent in regard to either the recognition of a text-based phone number 
30 within an electronic document (e.g. a Web page), or the subsequent 
iconification of a recognized text-based phone number to produce a "service 
object icon". Therefore, even in combination, Shachar '592 and Shachar '576 
fail to meet the claimed invention. 

35 Applicant therefore submits that independent Claims 1,15 and 21, as amended, 
overcome the Examiner's rejections under 35 U.S.C. §1 03(a) as being 
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unpatentable over Shachar '592 in view of Shachar '576. As Claims 2-14, 16- 
20 and 22 inherently contain the limitations of the claims they depend from, 
Applicant respectfully submits that they are patentable as well. 

5 Furthermore, in regard to Claim 12, the Examiner previously conceded that 
"Shachar '576 does not explicitly teach parsing algorithm method". 

As well, as disclosed in the Application as filed, the parsing function is used to 
"pattern recognize a telephone number contained therein", wherein, as cited in 
10 Claim 12, as previously amended, the parsing algorithm comprises the steps of: 

"developing a set of Picture Formats for the patterns of phone numbers; 
reading an accessed electronic document; 

checking every character in said text-based information within said 
15 electronic document to determine if said character is a numeric character; 

applying a pattern-recognition algorithm to sequentially check a 
character following an identified numeric character to determine if said following 
character is any of numeric or an interspersed text or punctuation character; 
caching a series of consecutive identified said numeric characters; and 
20 comparing said cached series to said Picture Formats; 

wherein a matching format indicates a text-based telephone number." 

As discussed above, the browser program disclosed in Shachar '576 merely 
formats a browser display screen, based on previously defined attributes. 
25 Shachar '576 does not disclose the detailed analysis of the previously defined 
attributes to recognize text-based phone numbers and iconify them. 

Both Shachar '592 and Shachar '576 fail to recognize the mere existence of 
previously uniconified {i.e. untagged) text-based telephone numbers, commonly 

30 having different formats. It would therefore be unreasonable to assume that 
"Shachar must include a parsing algorithm which performs similar function as 
claimed", as previously suggested by the Examiner. The multiplicity of steps 
involved {e.g. developing a set of Picture Formats, caching series of 
consecutive numbers, comparing cached series to Picture Formats, matching 

35 formats) for the patterns of phone numbers in the Applicant's parsing algorithm 
for "pattern recognizing a telephone number", as cited in Claim 12 in the 
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Application as filed, would require undue experimentation to develop the cited 
method, which is neither taught nor suggested either Shachar '592 or Shachar 
'576, and the shear multiplicity of steps is too involved to be considered 
obvious. 

5 

Furthermore, in Claim 15, as amended, the method applies a "parsing algorithm 
to text-based information other than previously iconified information within the 
Web page to pattern-recognize a text-based telephone number contained 
therein", and that coding is added to the representation of the Web page, to 
10 produce a selectable telephone number icon associated with the recognized 
text-based telephone number". 

As discussed above, Shachar '576 fails to "apply a parsing algorithm to the text- 
based information of a Web page to pattern- recognize a text-based telephone 
15 number contained therein", nor does Shachar '576 add "coding to produce a 
selectable telephone number icon associated with the recognized text-based 
telephone number". Therefore, Applicant submits that Claim 15 overcomes the 
Examiner's rejection of Claim 15 under 35 U.S.C. § 103(a) as being 
unpatentable over Shachar. 

20 

4b. In regard to Claims 2-7 and 13, the Examiner conceded that Shachar '592 
fails to disclose the claimed invention. 

Applicant respectfully submits that, as Claims 2-7 and 13 depend from 
25 amended Claim 1, and inherently contain the limitations of the claims they 
depend from, Claims 2-7 and 13 are patentable as well. 

The Applicant therefore respectfully submits that Claims 1-22, as amended, 
overcome the rejections under 35 U.S.C. § 103 set forth in this Office Action. 
30 Applicant submits that there is no new matter. 



35 



18 



Attorney Docket No. INFG0002 



CONCLUSION 



Based on the foregoing, the Applicant considers the invention to be in condition 
for allowance. The Applicant earnestly solicits the Examiner's withdrawal of the 
5 rejections set forth in the above referenced Office Action, such that a Notice of 
Allowance is fonA^arded to the Applicant, and the present application is therefore 
allowed to issue as a United States patent. 



Respectfully Submitted, 
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Michael A. Glenn 
Reg. No. 30,176 
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